As mobile devices like cellular phones have evolved into capable computing platforms, it has become increasingly common for end-users to perform important tasks (e.g., banking, online purchases, etc.) and/or store sensitive information (e.g., passwords, credit card numbers, email, work documents, etc.) on such devices. This trend has given rise to the need for mobile devices to implement user verification techniques—in other words, techniques that verify the identities of device users in order to, e.g., regulate the tasks the users can perform or the data they can access.
Existing mobile devices support a relatively simple user verification paradigm in which a user first enrolls his/her identity by supplying a predefined type of security metadata to his/her device, such a password, a PIN, a line pattern, a fingerprint, a text-dependent voice sample, or the like. Then, when the user wishes to perform a secured action, the mobile device asks the user to provide the same security metadata supplied at the time of enrollment, and attempts to match the provided metadata with the enrolled metadata. If a match is made the action is allowed, and if a match is not made the action is disallowed.
While the foregoing approach is functional, it also suffers from a number of drawbacks. First, since the user is required to explicitly provide his/her security metadata each time he/she wishes to be verified, the verification process can become burdensome for the user over time, particularly if the user needs to provide such metadata on a regular basis. This also means that, from a practical perspective, user verification cannot be performed continuously in the background (e.g., once every X minutes or hours, in order to ensure the device has not been stolen or otherwise compromised).
Second, since the approach above relies on a single type of verification model at a time, the verification may fail (e.g., return a false negative or a false positive) in certain contexts. For example, a vision-based face verification model may not work well in low light, or speech-based speaker verification model may not work well in a noisy environment. This, in turn, may reduce the user's confidence in, and likelihood to enable/use, the verification system.